Server, terminal control device and terminal authentication method

ABSTRACT

Information on whether a prefix is distributable to a MN is held by a CA. The server section of the HA allots prefix information to a MN approved by the CA. When the server section of the HA receives an IKE packet from the MN, the server section generates an IPsec SA after checking the prefix information in the server section. The server section allows an MN location registration request to fulfill the IPsec SA. The CA approves distribution of a prefix to the MN and verifies that the MN is genuine by generating an IPsec SA with the HA by utilizing the prefix distributed by the MN.

PRIORITY CLAIM

This application claims priority under 35 USC 119 to Japanese patentapplication P2003-064329 filed Mar. 11, 2003, the entire disclosure ofwhich is hereby incorporated by reference.

FIELD OF THE INVENTION

The present invention relates to a server, mobile control device, andterminal authentication method. The present invention relates inparticular to a server, home agent device and terminal authenticationmethod for guaranteeing and issuing public key certifications incommunication systems using mobile IP protocol.

BACKGROUND OF THE INVENTION

The IETF (Internet Engineering Task Force) is evaluating specificationsfor Mobile IPv6 (Ref. Mobility Support in IPv6<draft-ietf-mobileip-ipv6-19.txt>, Work in Progress).

The elements comprising the Mobile IPv6 network are a mobile node (MN),a home agent (HA), and correspondent node (CN).

The MN is assigned an IP address (home address) that does not changeeven if the MN moves. A link possessing a prefix identical to the homeaddress is called a home link. The HA manages MN location information(binding cache) in locations other than the home link.

The MN acquires a Care of Address (hereafter CoA) for links other thanthe home link. The MN that is not within the home link receives routerreports (advertisements) sent periodically by a router within thevisited link. The MN senses movement by detecting a prefix differentfrom the home address and generates a CoA. The MN registers (stores)information linking the CoA and home address within the HA.

The MN contains a home agent address discovery function (function forfinding the HA address) and may actively search for the IP address ofthe HA. The MN first of all creates a Mobile IPv6 Home-Agents AnycastAddress from the prefix of the home link. The MN sends an ICMP HomeAgent Address Discovery Request to the address destination. This signalis received by one of the home link HA. The HA that received the signalsends an ICMP Home Agent Address Discovery Reply containing informationon the HA to the MN. The MN extracts the HA information from this signaland acquires the HA address. The MN sends a binding update for that HAaddress.

The HA receives the binding update and stores the MN locationinformation in the binding cache.

In order to function as a proxy for the MN, the HA sends a neighboradvertisement addressed to all-nodes multicast addresses of the homelink. The node that received that neighbor advertisement, storesinformation linking the MN home address and HA link layer address, inthe neighbor cache. The HA captures the packet addressed to the homeaddress of the MN.

Mobile IPv6 contains a function to notify MN outside the home link, ofhome network prefix information. For example, if the prefix of the homenetwork has been changed, the HA refers (searches) the binding cache andreports the prefix information (makes a mobile prefix advertisement) tothe MN among the registered positions. The MN may also make a request tothe HA for prefix information (mobile prefix solicitation).

The IP Security Protocol (IPsec) is the focus of attention as atechnology for achieving security on the IP network. This IPsec is atechnology for safely conveying IP packets by utilizing encryptiontechnology and certification technology. Mobile IPv6 is applying thisIPsec technology in the sending of location registration signals(binding updates) from the MN to the HA (Ref.draft-ietf-mobileip-mipv6-ha-ipsec-01.txt, Work in Progress).

This IPsec technology provides a security function by creating an SA(security association) among the devices using IPsec. The devicesutilizing IPsec contain a SPD (security policy database) and an SAD(security association database).

The security policy database (SPD) specifies the method for processingthe packets. The security association database (SAD) is a list of SA(security associations) held in the devices using IPsec. The SA isidentified by a SPI (Security Parameters Index).

The method for creating the SA includes a manual setting method and anautomatic creation method. The IKE (Internet Key Exchange) is a protocolfor automatically creating and managing these SA. The IKE automaticallygenerates the SA by making use of a proposal exchange function, afunction to generate a secret key, and a certification function for IKEcorrespondent nodes.

Certification methods specified for IKE correspondent nodes are thePre-shared key authentication method, public key certification method,digital signature authentication method, etc. The digital signatureauthentication method is highly flexible since it need not share keyinformation beforehand with the other communication party (orcorrespondent node). The digital signature certification method is usedby the CA (Certification Authority) for issuing public keycertifications. The format for public key certification is the specifiedin X. 509.

The CMP (Certificate Management Protocol) is a protocol for issuing andmanaging electronic certifications. The CMP is specified in IETFRFC2510. The CMP is utilized in transport protocols in HTTP (HyperTextTransfer Protocol) and TCP (Transmission Control Protocol).

One technology proposed for localized mobility management based onMobile IPv6 is Hierarchial Mobile IPv6 mobility management (HMIPv6)(Ref. draft-ietf-mobileip-hmipv6-07.txt, Work in Progress). This HMIPv6contains a MAP (Mobile Anchor Point) between the HA and MN. The MNreceives a router advertisement containing MAP options from the AR(Access Router), acquires the MAP IP address, and generates a RCOA(Regional Care of Address) and LCoA (On-link CoA). The MN compatiblewith HMIPv6 registers location information in the MAP and HA. The MAPmanages the binding information of the MN RCoA and LCoA. The HA managesthe binding information of the MN home address and RCoA. The MN onlyrewrites (updates) the MAP location information when the MN has movedwithin the MAP.

The IETF is currently evaluating IPv6 Prefix Delegation Options forDHCPv6 (hereafter, DHCP-PD)(draft-ietf-dhc-dhcpv6-opt-prefix-delegation-01.txt, Work in Progress).The DHCP-PD is a function making use of DHCP (Dynamic Host ConfigurationProtocol) to assign IPv6 prefixes (group) to sites from the addressassignment side.

The elements comprising the DHCP-PD are the delegating router and therequesting router. The requesting router asks the delegating router toassign an IPv6 prefix (group). The delegating router selects an IPv6prefix (group) and sends that to the requesting router. The DHCP-PD forexample, is utilized by the ISP (Internet Service Provider) whenassigning prefixes to subscribers.

In a communication system mutually connected to both a zone A and zoneB, when a mobile node (MN) belonging to zone A has moved to zone B, thatMN registers its location in the HA of zone A. The location registrationsignal (binding update signal) is then subjected to IPsec processing.

The related art has the problem that security cannot be maintained whenmanually setting the SA (security association) for the HA and MN, andinformation about the key used in encryption has leaked out. Also, usingthe Mobile IPv6 prefix report (advertise) function and HA addressdiscovery function will change the home address of the MN or HA address.The method for manually setting the SA between the MN and HA istherefore not practical during system operation. There is also no meansfor currently verifying on Mobile IP if the MN is genuine.

SUMMARY OF THE INVENTION

The present invention may provide a terminal authentication method thatutilizes Mobile IP technology. In particular, this invention may providea procedure for authenticating terminals by linking a digital signatureauthentication method with a Mobile IP location registration procedure,and by creating and holding a SA (security association) for a homeaddress linked to the HA issuing public key certifications.

The present invention may also to provide a system for authenticatinggenuine terminals by linking a DHCP-PD delegating router and CA, and bylinking a DHCP-PD delegating router and HA, when the MN is dynamicallyacquiring a home address.

The present invention in particular may have the following features whena terminal x of a home network with an HA belonging to zone A, utilizesa DHCP-PD section in zone B to acquire a home network prefix.

-   1) The DHCP-PD delegating router may allot prefix information to a    terminal approved by CA.-   2) The HA creates an SA for an IP address possessing a prefix    allocated by that delegating router, and approves location    registration to satisfy the SA.

The present invention may also to provide an authentication method for aDHCP delegating router to allot prefix information to terminals approvedby the CA, when a communication device belonging to zone B possesses aHMIPv6 compatible MAP, and that communication device receives a bindingupdate from the MN and starts the DHCP-PD section.

The present invention may also provide a communication method for the HAto report prefix information to a terminal approved by CA.

More specifically:

-   (1) The CA may be comprised of a system for communicating with a    DHCP-PD delegating router section 16 as show in FIGS. 2, 20, and 23.    The CA issues a public key certification to the terminal and allows    reporting prefix information.-   (2) The terminal is comprised of a Mobile IPv6 function, an IPsec    function, and a function to hold information required for a digital    signature name. Information required for authenticating a digital    signature name may be received from an external storage device. The    terminal need not be a mobile terminal.-   (3) The terminal control device contains a delegating router    function for a DHCPv6 Prefix delegation option (hereafter, DHCP-PD).    The delegating router function is comprised of a system for    communicating with CA, and a system for reporting prefix information    to a terminal approved by CA.-   (4) The terminal control device inquires about prefix information to    the DHCP-PD delegating router function when a request to create an    SA is received from the terminal. The terminal control device    comprises a system to create an SA among terminals if the terminals    utilize prefixes allotted by the delegating router function.-   (5) The terminal control device may contain a storage device or    system to hold the public key certification for a terminal. Prefix    information may be conveyed to terminals approved by the CA.

DETAILED DESCRIPTION OF THE DRAWINGS

FIG. 1 is a concept drawing showing the structure of the communicationnetwork of the present invention;

FIG. 2 is block diagram of the home agent HA1;

FIG. 3 is a binding cache management table contained in HA1:

FIG. 4 is a prefix control table contained in HA1;

FIG. 5 is a flow chart of the prefix delegation processing routinecontained in the DHCP-PD section of HA1:

FIG. 6 is a flow chart of the IPsec processing routine contained in theIPsec of HA1;

FIG. 7 is a block diagram of the certification authority CA3;

FIG. 8 is a drawing of a prefix allocation control table contained inCA3;

FIG. 9 is a flow chart of the public key certification issue routinecontained in A3;

FIG. 10 is drawing showing the format of the IPv6 packet;

FIG. 11 is a drawing showing an example of a CMP message;

FIG. 12 is drawing showing the format of the DHCPv6 packet;

FIG. 13 is a drawing showing the format of an ISAKMP packet;

FIG. 14 is a drawing showing the format of an ISAKMP packet whenconfirming an identity of IKE phase 1;

FIG. 15 is an example of a binding update message;

FIG. 16 is an example of a binding acknowledgement message;

FIG. 17 is a sequence drawing 1 for location registration (bindingupdate) and authentication in the present invention;

FIG. 18 is a sequence drawing 2 for location registration (bindingupdate) and authentication in the present invention;

FIG. 19 is a concept drawing showing the structure of the communicationnetwork of the second embodiment;

FIG. 20 is a block diagram of the communication device 2 of the secondembodiment;

FIG. 21 is a sequence drawing for location registration (binding update)and authentication in the second embodiment;

FIG. 22 is a concept diagram showing the structure of the communicationnetwork of the third embodiment;

FIG. 23 is a block diagram of the communication device 2 of the thirdembodiment;

FIG. 24 is a sequence drawing for location registration (binding update)and authentication in the third embodiment;

FIG. 25 is a sequence drawing 1 for location registration (bindingupdate) and authentication in the fourth embodiment;

FIG. 26 is a sequence drawing 2 for location registration (bindingupdate) and authentication in the fourth embodiment; and

FIG. 27 is a sequence drawing 3 for location registration (bindingupdate) and authentication in the fourth embodiment.

FIG. 28 is an alternative sequence drawing 1 for location registration(binding update) and authentication in the first embodiment.

FIG. 29 is an alternative sequence drawing 2 for location registration(binding update) and authentication in the first embodiment.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS First Embodiment

The first embodiment of the present invention is described next whilereferring to the accompanying drawings. In this embodiment, the HA isequivalent to a terminal control device.

The MN authentication method and location registration method used whenthe Mobile IPv6 compatible mobile node (MN) is in a network (hereafter,visited network) other than the home link (hereafter, home network) isdescribed in detail.

FIG. 1 shows the structure of the communication network of the presentinvention. The communication network is comprised of a home network 8for MN4, an IP network 7 and a visited network 5 (5 a, 5 b). In thisembodiment, the home network 8, the IP network 7 and the visited network5 are IPv6 networks. The MN4 is a mobile node (MN) compatible withMobile IPv6. The information appliance terminal 9 contains MN functionscompatible with Mobile IPv6. The visited network 5 and IP network 7, andthe IP network 7 and home network 8 are connected by router or a gatewaydevice. The visited network 5 and home network 8 may also be directlyconnected by a router or a gateway device.

The home network 8 contains a home agent HA1. The HA1 is a home agent(HA) compatible with Mobile IPv6. The HA1 manages MN locationinformation other than in the home network 8.

The visited network 5 (5 a, 5 b) is comprised of a communication device2 (2 a, 2 b) and a router 6 (6 a, 6 b, 6 c, 6 d). The communicationdevice 2 is comprised of an interface with a router 6, and an interfacewith an IP network 7. The router 6 contains a device authenticationfunction.

Instead of the device authentication function, the router 6 may utilizea system for communicating with a server possessing a deviceauthentication function.

The IP network 7 contains the CA3. The home network 8 or the visitednetwork 5 may also contain the CA3.

FIG. 2 shows the structure of the HA1 installed in the home network 8 ofMN4. The HA1 is comprised of a server section 11, (11 a, 11 b) , aserver section 12, and an interface section (IF) 19 (19 a, 19 b, 19 m,19 n) containing a line 18 (18 a, 18 b, 18 m, 18 n) and, a switchsection 17 (17 a, 17 b).

The server section 11 mainly contains a packet transmit-receiveprocessor 13, an IPsec processor 14, and a mobile IP processor 15. Thepacket transmit-receive processor 13 contains a function to transmit orreceive data packets. The IPsec processor 14 contains mainly an SPD, SADand an IPsec processing routine 70. The IPsec processor 14 authenticatespackets and performs encoding. The IPsec processor 14 acquires serversection 11 public key certification from the CA3. The mobile IPprocessor 15 contains a Mobile IPv6 for the home agent (HA) function.The mobile IP processor 15 contains a binding cache management table310.

FIG. 3 shows the table structure of the binding cache management table310. The binding cache management table 310 stores at least a Care ofAddress (CoA) 312 acquired by the MN in the visited network for the MNhome address 311, and a Lifetime 313 showing the effective period of thebinding cache.

The server section 12 contains a packet transmit-receive processor 13and a DHCP PD section 16.

The DHCP PD section 16 contains a DHCP-PD delegating router function. Italso contains mainly a prefix control table 320, a prefix delegationprocessing routine 60, and a table linking the IA_PD for identifying theDHCP-PD and an MN identifier.

FIG. 4 shows the structure of the prefix control table 320. This prefixcontrol table 320 in DHCP PD Section 16 stores at least an IAID322showing the prefix (group), an allocated prefix 323, and a lifetime 324of the prefix, and shows the corresponding relation with the DHCP Clientidentifier 321. The DHCP-PD section of the server 12 is mounted in HA1,however a DHCP-PD section may be mounted in a server separate from theHA1.

FIG. 7 shows the structure of the certification authority (CA) 3installed in the IP network 7. The CA3 is comprised a CPU31, a memory32, and an interface section (IF) 33 containing the line 34, and a bus35 connecting these components.

The memory 32 is comprised of at least a prefix allocation control table330 and, a public key certification issue routine 80, and a certifyinginformation storage table.

FIG. 8 shows the table structure of the prefix allocation control table330. The prefix allocation control table 330 stores a Prefix issue OKflag 332 showing whether or not permission to issue a prefix was issuedto the identifier (ID) 331 of the terminal.

The sequence for location registration and authentication of MN4 in thenetwork 5 b shown in FIG. 1, is described according to the sequenceshown in FIG. 17 and FIG. 18. In this embodiment, the MN4 contains asystem to load the identifier and secret key and public key from astorage device typically a Secure Multimedia Card (SMMC), etc. The MN4further contains a DHCP-PD requesting router function.

When power is turned on, the MN4 receives (101) a router advertisementfrom the router 6 c belonging to the network 5 b. The MN4 searches the Mbit of the router advertisement and decides on a method for acquiringthe CoA (Care of Address). If the M bit is 1, then MN acquires the CoAusing the automated structure of the IPv6 statefull address. If the Mbithas not been set, then the Mbit creates a CoA (102) utilizing theautomated structure of the IPv6 stateless address.

The MN4 next sends a device authentication request to the router 6 c(103). The router 6 c authenticates the device, using the device ID as asearch (or retrieval) key. The router 6 c sends (104) a deviceauthentication response including the authentication results to MN4. AMAC address for example is utilized as the device ID.

When device authentication ends correctly, the MN4 loads the MN4identifier and secret key and public key from a storage device such asthe SMMC. The MN4 identifier specifies for example, a FQDN (fullyqualified domain name) or a distinguished name of X.500.

The MN4 sends a public key certification issue request containing an MN4public key and identifier to the CA3 (105). A CMP (CertificateManagement Protocol) is utilized for sending and receiving the publickey certification.

FIG. 11 shows a packet format S1 containing a CMP message.

FIG. 10 shows the format of an IPv6 packet.

The CMP message S1 is stored in data section 43B within the payload 43of the IPv6 packet.

The CA3 receives the request and starts the public key certificationissue routine 80.

FIG. 9 shows the public key certification issue routine 80. The CA3confirms whether a certification can be issued to MN4 using the MN4identifier (81). If a certification can be issued then the CA3 issues apublic key certification for MN4. The CA3 next creates a new entry forMN4 in the prefix allocation control table 330, and sets up a prefixissue OK flag (82, 106). The CA3 sends a public key issue requestresponse containing a public key certification for MN4 and a public keyfor CN3, and ends this routine (83, 107).

When the certification cannot be issued in step 81, or in step 82 whenthe certification cannot be issued for a public key for MN4, the CA3issues a certification issue request response (84) to notify the MN4 ofthe error and ends this routine.

The server section 11 of HA1 holds an identifier, a HA secret key and aHA public key. This procedure is similar to the procedure used by the MNwhich has its own MN secret and MN public key. The server section 11acquires the public key certification from the CA3 (for server section11) (183).

After acquiring the MN's public key certification, the MN4 starts theprefix request process and acquires a home prefix.

To find a DHCP server with a prefix that can be allocated, the MN4 sendsa DHCP solicit message to the All_DHCP_Relay_Agents_and_Servers address(108). This solicit message includes a DHCP client identifier (clientidentifier option) and IA_PD option. An IAID showing a group (IA_PD)applying a prefix within the MN is set in the IA_PD options.

FIG. 12 shows an S2 packet format containing a DHCPv6 message. TheDHCPv6 is an application protocol using UDP/IP in the transport layer.The DHCP message S2 is stored in the data section 43B of payload 43 ofthe IPv6 packet. The DHCP message specifies the value in themessage-type field 51. The option parameter of the DHCP message is setin the Options field 53.

Here, the server section 12 for HA1 receives the DHCP solicit message(108). The server section 12 for HA1 then starts up the prefixdelegation processing routine 60.

FIG. 5 shows the prefix delegation processing routine 60.

The server section 12 loads the IAID from the IA_PD options of the DHCPsolicit message, and decides (61) if a prefix can be allocated to theIAID. If a prefix can be allocated then the server section 12 designatesan IA_PD from the IAID containing that DHCP solicit message. The serversection 12 searches the table linking the MN4 identifier and IA_PD,using the IA_PD as a search (retrieval) key, and decides the MN4identifier. The server section 12 sends a request (62, 109) containingMN4 identifiers to the CA3.

When an inquiry is received, the CA3 searches the prefix allocationcontrol table 330 using the NN4 identifier as a search key (110).

The CA3 searches for the MN4 entry generated in step 106. The CA3confirms that a prefix issue OK flag is set for the applicable entry,and sends a response showing prefix allocation is allowed, to the server12 (63, 111).

When a response is received, the server section 12 searches the DHCPclient identifier with the IAID contained in that DHCP solicit message,and the prefix control table 320. When the applicable entry is notpresent in the prefix control table 320, the server section 12 generatesa new entry in the prefix control table 320, and stores an IAID322 andDHCP client identifier 321 that are contained in that DHCP solicitmessage. The server section 12 then sends a DHCP advertise message tothe MN4 (64, 112). This advertise message contains an identifier forserver section 12 (server identifier option), an identifier for MN4(client identifier option), and the IA_PD options received in step 108.The advertise message from the server section 12 may also include IPv6prefix information for allocation.

When the server 12 cannot allocate the IPv6 prefix to the IAID in step61, or when the CA3 does not allow allocation of the prefix in step 63,then the server 12 sends an advertise message containing a status codeoption to the MN4 showing the prefix cannot be allocated and ends thisroutine (67).

When allocation (or distribution) of the prefix is approved, the MN4sends a DHCP request message containing IA_PD options to the serversection 12 and requests IPv6 prefix information (113).

When the advertise message received in step 112 contains an IPv6 prefixmessage, the request message contains the prefix that the MN4 needs touse.

Here, returning to FIG. 5, the description of the prefix delegationprocessing routine 60 continues.

When the DHCP request message is received (65), the server section 12loads the IAID and specifies the IPv6 prefix for allocation. When therequest message contains IPv6 prefix information, then the prefix neededfor use by MN4 is approved.

The server section 12 next searches the prefix control table 320 withthe IAID and DHCP client identifier contained in the DHCP requestmessage. The server section 12 detects and entry generated in step 64,and stores the IPv6 prefix for distribution and the prefix lifetime inthe applicable entries. The server section 12 sends a DHCP reply messagecontaining the prefix information to MN4 (66, 114), and ends thisroutine.

When a prefix for allocation to MN4 could not be specified in step 65,or when there was no applicable entry in the prefix control table 320 instep 66, then the server section 12 sends a DHCP reply message (68) toMN4 to report the error and ends this routine.

The MN4 extracts IPv6 prefix information from that DHCP reply message.The MN4 creates a home address from the prefix information and the MN4interface identifier.

The MN4 next specifies the HA address using the HA (home agent) addressdiscovery function. The MN4 sends the Home Agent Address DiscoveryRequest (116) to the Mobile IPv6 Home-Agents Anycast Address set in thehome network prefix received in step 114.

One of the HAs which process the same prefix as the Mobile IPv6Home-Agents Anycast Address may receive the Home Agent Address DiscoveryRequest.

The server section 11 a of HA1 receives the Home Agent Address DiscoveryRequest. The server section 11 a sends the Home Agent Address DiscoveryReply to the MN4 (117).

The MN4 receives the Home Agent Address Discovery Reply and acquires theHA address (address of server section 11 a) (118).

The MN4 next utilizes an IKE to create an IPsec SA for use between theserver section 11 a and MN4.

In IKE phase1, an ISAKMP SA is established between the MN4 and serversection 11 a. The ISAKMP SA is a control channel for the IKE. The MN4proposes ISAKMP SA parameters (121) utilizing the SA payload in theserver section 11 a.

FIG. 13 shows the ISAKMP packet format S3. The packet format used by IKEis specified in the ISAKMP protocol. The IKE transport protocol isUDP/IP.

The ISAKMP packet S3 is stored in the data section 43B of payload 43 ofthe IPv6 packet. The ISAKMP packet S3 is comprised of an ISAKMP header55 and one or more payloads 56. The payload 56 contains for example, anSA payload to transport the proposed SA, an identification payload toexchange the ID information, and a signature payload to send the digitalsignature, etc.

The server section 11 a selects an acceptable proposal from the SApayload received in step 121 and returns it to the MN4 (122).

The MN4 and server section 11 a next exchange Diffe-Hellman publicvalues and random numbers obtained per Nonce (123, 124) and generate asecret key.

The MN4 and server section 11 a next exchange ID information forverifying a personal identity. In this embodiment, the signal sent whenconfirming if the identity attribute is the actual person is defined asthe personal identity check signal. FIG. 14 shows the ISAKMP packetformat S4 utilized in checking the personal identity for IKE phase 1.The ISAKMP packet S4 contains the identification payload 56A, signaturepayload 56B and the certificate payload 56C.

The MN4 sends (125) the ISAKMP packet utilized in the personal identitycheck to the server section 11 a. The identification payload 56A of thisISAKMP packet 125 includes the home address generated by MN4 in step115. The MN4 calculates the hash value, executes the digital signatureutilizing the MN4 public key in that hash value, and sets it in thesignature payload 56B. The certificate payload 56C includes MN4 publickey certification that CA3 issued.

The server section 11 a extracts the MN4 digital signature from thesignature payload 56B of packet 125. The server section 11 a thendecodes the digital signature using the MN4 public key. The MN4 publickey is acquired from the certificate payload 56C of packet 125.

The server section 11 a confirms the personal identity of the packetsender MN4 by comparing the hash value calculated from the receivedpacket 125 and the decoded value of that digital signature.

The server section 11 a next extracts the MN4 home address from theidentification payload of packet 125. The server section 11 a sends aninquiry containing the home prefix to the server section 12 (126). Theserver section 12 searches the prefix control table 320 using the prefixcontained in that request 126 as a search key. If an applicable entry ispresent in the prefix control table 320, then assigning of the prefix iscomplete (127). The server section 12 sends a reply to the serversection 11 a notifying that prefix allocation is complete (128).

If allocating of the prefix is complete, the server section 11 acontinues the processing of IKE phase 1. The server section 11 aexecutes the digital signature using the public key of server section 11a in the hash value. The server section 11 a sends the ISAKMP packetcontaining the digital signature to MN4 (129). The IP address of serversection 11 a is set in the identification payload of the ISAKMP packet129. This ISAKMP packet may be included in the public key certificationof server section 11 a. The public key certification of server section11 a was issued in step 183. Alternatively the public key certificationof server section 11 a may be issued in step 181 and 182 of FIG. 29, andin this case the step 183 is needless (FIG. 28).

The MN4 receives the packet 129 and confirms if the other party in theIKE communication using the public key of server section 11 a isgenuine. The MN4 acquires the server section 11 a public key from thepublic key certification in packet 129 or acquires it from CA3.

The ISAKMP SA has now been established between MN4 and the serversection 11 a.

The IPsec SA is next created in IKE phase 2, for MN4 and server section11 a. This IPsec SA is utilized when IPsec processing and forwarding thepackets between the MN4 and server section 11 a. The payload for ISAKMPpackets sent and received in IKE phase 2 is encoded using the ISAKMP SAestablished in IKE phase 1.

The MN4 sends an ISAKMP packet to the server section 11 a. An SA payloadcontaining the IPsec SA proposal, a Nonce payload, and a hash payloadwere set in this ISAKMP packet (130). The server section 11 a then sendsto the MN4, the ISAKMP packet in which are set the IPsec SA payloadcontaining the accepted IPsec proposal, the Nonce payload, and the hashpayload (131).

The MN4 sends the ISAKMP packet containing the hash payload to theserver section 11 a (132). The server section 11 a receives this packet(132) and confirms that MN4 has received the packet 131. The aboveprocess generates two IPsec SA (the IPsec to the server section 11 afrom MN4, and the IPsec SA to the MN4 from the server section 11 a). Theserver section 11 a and the MN4 store the IPsec SA (SPI, MN4 homeaddress, and server section 11 a address, etc.) in the respective SAD.

The MN4 sends a binding update adapted for the SA generated in IKE phase2 to the server section 11 a (133). The MN4 temporarily stores theaddress of server section 11 a in the binding update list control table(134).

FIG. 15 shows the binding update message format S11 compatible withIPsec. The IPv6 destination options header 401, IPsec header (AH headeror ESP header) 402, and the IPv6 mobility header 403 are stored in theIPv6 packet extension header 42.

The MN4 stores the following values in the binding update sent to theserver section 11 a. The CoA of the MN4 is set in the source address 41a of the IPv6 packet header. The home address that the MN4 generated instep 115 is set in the home address field of the IPv6 DestinationOptions Header 401.

The server section 11 a receives this binding update 133 and starts theIPsec processing routine.

FIG. 6 shows the IPsec processing routine 70. The IPv6 DestinationOptions Header 401 is processed first (71). More specifically, theDestination Options Header value (home address) and the source addressvalue (CoA) are exchanged with each other.

The server section 11 a next searches the SAD for the type of IPsec (AHor ESP), SPI value, and destination address, and specifies the IPsec SA.When the received packet has been encoded, the server section 11 a firstdecodes the received packet and checks that it matches the specifiedIPsec SA (72). The server section 11 a next searches the SPD, and checkswhether the (now) reconstructed packet can be accepted (73).

If the packet can be accepted, then the IPsec processor 14 of serversection 11 a sends the reconstructed packet to the mobile IP processor15.

The mobile IP processor 15 registers the MN4 location (makes a bindingupdate) (74).

The mobile IP processor 15 searches the binding cache management table310 using the MN4 home address as a search (retrieval) key. If there isno MN4 entry in that binding cache management table 310, then an MN4entry is added to the binding cache management table 310 (135). The MN4sets the CoA acquired in the visited network 5 b, into the Care ofAddress 312 entry.

If the processing in step 72 and step 73 did not end correctly, then theserver section 11 a discards the received packet and ends this routine(78).

The mobile IP processor 15 sends the packet to the IPsec processor 14for sending a binding acknowledgement adapted to IPsec, to the MN4. TheIPsec processor 14 searches the SPD and investigates the packet securitypolicy (75). When found that the packet is usable with IPsec, a matchingSA is detected from the SAD. The IPsec processor 14 adds a routingheader 404 to this packet and applies IPsec (76). The server section 11a next interchanges the routing header value and the destination addressvalue. The server section 11 sends a binding acknowledgement subjectedto IPsec processing, to MN4 (77, 136) and then ends this routine.

FIG. 16 shows the format S12 of a binding acknowledgement messagesubjected to IPsec. The IPv6 routing header 404, the IPsec header (AHHeader or ESP header) 402, and the IPv6 mobility header 403 are storedin the IPv6 packet extension header 42. The server section 11 a storesthe following values in the binding acknowledgment sent to the MN4. TheCoA of MN4 is stored in the destination address 41 b of the IPv6 packetheader. The MN4 home address is stored in the home address field of theIPv6 routing header 404.

When the binding acknowledgement is received, the MN4 searches the SADand specifies an SA. When the received packet has been encoded, thereceived packet is checked after decoding, to find if it matches the SA.The SPD is also searched and a check made to determine if thereconstructed packet can be accepted. If acceptable, the MN4 registersthe entry temporarily stored in step 134, into the binding update listcontrol table (137).

Here, the MN4 may register the identification information (for exampleFQDN) and information matching the home address acquired in step 115,into the home network 8, the visited network 5, or the locationinformation control device (for example a DNS server device) belongingto the IP network 7.

The information appliance terminal 9 is comprised of a Mobile IPv6function and a DHCP-PD requesting router function. An authenticationmethod can be used with the information appliance terminal 9 if a publickey certification is acquired from the CA3.

The first embodiment of the present invention can therefore provide anauthentication method for verifying the authenticity of the IPv6terminal, by linking a digital signature authentication method with aMobile IP location registration (binding update) procedure, and by theHA creating and holding an SA for the home address linked to the publickey certification.

The MN4 and HA1 server section 11 hold a public key certification issuedby the CA3. The HA1 server section 12 and the MN4 contain a DHCP-PDsection. By linking the CA3 and the HA1 server section 12, the HA1 cangive a prefix notification to the MN4 to whom prefix allocation wasapproved by CA3. The HA1 server section 11 can further provide anauthentication method for verifying the MN is genuine by generating anIPsec SA among the MN4 home prefix for the prefix that has beenallocated by the server section 12 already.

Second Embodiment

The second embodiment of the present invention is described next whilereferring to the accompanying drawings.

FIG. 19 shows the structure of the communication network of the secondembodiment of the present invention. The second embodiment ischaracterized in that the communication device 2 contains a DHCP-PDrequesting router function. In the example of the second embodiment, theIP network 7 contains an authentication server 10. The authenticationserver 10 controls information (ID, passwords, etc,) required forauthorizing access to the home network.

FIG. 20 shows the structure of the communication device 2 of the secondembodiment of the present invention. The communication device 2 iscomprised of a CPU 21, a memory 22, and an interface section (IF) 23 (23a, 23 b) containing a line 24 (24 a, 24 b), and a bus 25 connectingthese components.

The memory 22 is comprised mainly of a DHCP-PD section 26 containing aDHCP-PD requesting router function, and an authentication processor 27for authorizing access to the home network 8.

FIG. 21 shows the sequence for location registration (binding update)and authentication of MN4 in the second embodiment of the presentinvention.

The first embodiment and the second embodiment differ in theinstallation locations for the DHCP-PD requesting router function. Thecommunication device 2 (GW2) of the second embodiment contains a DHCP-PDrequesting router function, and sends and receives DHCP-PD messages.

The process from step 101 to step 107 is the same as the firstembodiment.

Hereafter, the process from step 141 onwards is described.

When a packet is received from the MN4, the GW2 requests that the MN4send authentication information (141). The MN4 sends an authenticationrequest containing an ID and password (142). The GW2 b sends a DHCPsolicit containing an IAID (143).

The server section 12 receives that DHCP solicit and specifies an IA_PDfrom the IAID. The server section 12 searches the table of correspondingMN4 identifiers and IA_PD using the IA_PD as a search (retrieval) key,and decides on an MN4 identifier.

The process from step 144 to step 146 is the same as steps 109 to step111 in the first embodiment.

When the reply 146 is received, the server section 12 sends a DHCPAdvertise (notification) to the GW2 b (147). Hereafter, the processingfrom step 148 to step 149 for the server section 12 is the same as inthe first embodiment.

When the DHCP reply 149 containing the prefix information is received,the GW2 b sends an authentication reply containing prefix information tothe MN4 (150). Hereafter, the MN authentication processing and thelocation registration (binding update) processing is the same as fromstep 115 to step 137 in the first embodiment.

The second embodiment of the present invention can therefore provide anauthentication method for verifying the authenticity of IPv6 terminalsnot containing a DHCP-PD section, by linking a digital signatureauthentication method with a mobile IP location registration (bindingupdate) procedure, even in cases where the communication device 2 isequipped with a DHCP-PD requesting router function.

The second embodiment can also provide a highly safe communicationservice by providing a function for authorizing access to HA from thecommunication device 2.

Third Embodiment

The third embodiment of the present invention is described next whilereferring to the accompanying drawings.

FIG. 22 shows the structure of the communication network of the thirdembodiment of the present invention. In addition to the functions of thesecond embodiment, the third embodiment is characterized by possessingHMIPv6 MAP functions. In the third embodiment, the MN4 is a mobileterminal compatible with HMIPv6.

FIG. 23 shows the structure of the communication device 2 of the thirdembodiment. The memory 22 of the communication device 2 contains anHMIPv6 processor 29 in addition to the functions shown in the secondembodiment. The HMIPv6 processor 29 provides the HMIPv6 compatible MAPfunctions. The HMIPv6 processor 29 contains a binding cache managementtable for holding information linking the RCoA and LCoA.

The sequence for location registration (binding update) andauthorization for MN4 in the network 5 shown in FIG. 22 are describedaccording to the sequence shown in FIG. 24.

The MN4 receives a router notification (router advertisement) containingMAP options from the router (AR: Access Router) 6 c belonging to thenetwork 5 b (161). The MN4 specifies the communication device (hereafterMAP) using the router advertisement information 161 and generates anRCoA and LCoA (162).

The process from step 103 to step 107 is the same as in the firstembodiment.

When the MN4 receives the public key certification from the CA3, itsends a binding update (location registration signal) to the MAP2 b(163).

In the third embodiment, the MAP2 b utilizes the receiving of thebinding update (location registration signal) to initiate authenticationprocessing. The process hereafter from step 141 to step 150 is the sameas the second embodiment.

When the processing up to step 150 ends correctly, the MAP2 b storesinformation linking the RCoA and LCoA of MN4, into the binding cachemanagement table of the HMIPv6 processor 29. The MAP2 b sends thebinding acknowledgement to the MN4 (164).

The MN authorization process and location registration (binding update)process hereafter are the same as from step 115 to step 137 of the firstembodiment. The third embodiment of the present invention can thereforeprovide an authentication method for verifying the authenticity of IPv6terminals not containing a DHCP-PD section, by linking a digitalsignature authentication method with a mobile IP location registration(binding update) procedure, even in cases where the communication device2 is equipped with a HMIPv6 function.

The third embodiment can also provide a communication service withhigher safety by the communication device initiating the accessauthentication processing for the home network when the HMIPv6 controlsignal is received.

Fourth Embodiment

The fourth embodiment of the present invention is described next whilereferring to the accompanying drawings. The structure of thecommunication network in the fourth embodiment is the same as in thefirst embodiment.

The fourth embodiment is characterized in that the server section 11 ofthe HA1 comprises a system to allocate the prefix to MN approved by theCA3, and in containing a MN4 public key certification control table.Information on the identification payload contained in the ISAKMP packetof IPsec phase 1 and information linked to the public key certificationsare stored in the public key certification control table.

In the fourth embodiment, the HA1 and the MN need not contain a DHCP-PDsection. The HA of the MN4 is the server section 11 a.

After the MN4 in the network 5 b shown in FIG. 1, has completed locationregistration (binding update) in the server section 11 a, the sequencefrom the HA1 server section 11 a notifying the MN4 of the prefix, to theMN4 once again completing location registration (binding update) isdescribed while following the sequence shown from FIG. 25 through FIG.27.

The sequence from step 101 to step 107 is the same as in the firstembodiment.

The MN4 next creates an IPsec SA in the server section 11 a.

The sequence from step 121 through step 125 is the same as in the firstembodiment. The MN4 sends to the server section 11 a, an ISAKMP packet125 containing an identification payload set with the M4 home address,and with a certificate payload set with the MN4 public keycertification.

The server section 11 a loads the certificate payload and identificationpayload information from the packet 125, and adds the MN4 entry to thepublic key certification control table (171). If an MN4 entry is alreadypresent, then the applicable entry is rewritten (updated).

The sequence from step 129 to step 132 is the same as in the firstembodiment.

The MN4 carries out location registration (binding update) utilizing anIPsec SA generated by MN4 and the server section 11 a. The locationregistration (binding update) is the same as the first embodiment (fromstep 133 to 137).

When the server section 11 a is for example changing its own prefix, theMN4 current performing the binding update is notified of the prefix bythe server section 11 a.

The server section 11 a first searches the binding cache managementtable 310 and then detects the MN4 entry generated in step 135. Theserver section 11 a next searches the public key certification controltable using the MN4 home address as a search (retrieval) key and loadsthe MN4 public key certification made in step 171.

The server section 11 a specifies the MN4 identifier from the public keycertification, and sends an inquiry along with this MN4 identifier tothe CA3 (172, 173).

When this inquiry is received, the CA3 searches the prefix allocationcontrol table 330 using the MN4 identifier as a search (retrieval) key.

The CA3 detects the MN4 entry created in step 106. The CA3 confirms thatan applicable entry is set in the prefix issue OK flag (174). The CA3sends a reply to the server section 11 a showing a prefix can beallocated (175).

When the reply is received, the server section 11 a sends a mobileprefix advertisement to report the prefix information to the MN4 (176).The server section 11 a applies the IPsec SA generated in steps 130 to132, in the mobile prefix advertisement message.

The MN4 loads the prefix from the mobile prefix advertisement. The MN4detects changes in the home prefix, and generates a home address. Theprocess from creating the home address to completion of locationregistration (binding update) is the same as step 115 through 125 in thefirst embodiment (step 129 through step 137).

The fourth embodiment of the present invention is therefore capable ofnotifying the MN4 of the prefix information, by linking HA1 and CA3after confirming the MN is genuine.

As clearly shown by the above embodiments, the present inventionprovides an authentication method for verifying that the IPv6 terminalis genuine by linking a digital signature authentication method with aMobile IP location registration (binding update) procedure.

In particular, an authentication method can be provided for verifyingthe terminal x is genuine when performing Mobile IP binding updates(location registration) with a terminal x an HA belonging to zone A as ahome network in zone B, with the method comprising a system for aDHCP-PD delegating router function belonging to zone A to distribute aprefix to the terminal X belonging to zone B; and further comprising: 1)a system for inquiring whether a DHCP-PD delegating router function canallocate a prefix to CA, 2) a system for inquiring whether the HAcontains prefix information in the DHCP-PD delegating router function,3) a system for acquiring a terminal x public key from CA or terminal xwhen the HA is creating IPsec SA with the terminal x, 4) a system forthe HA to approve only location registration (binding update) subjectedto the IPsec generated above in 3).

The above described authentication method for verifying a terminal x notcomprising a DHCP-PD section, can be provided if a communication devicemutually connected to both zone A and zone B contains a DHCP-PDrequesting router function and a function authorizing zone A access.Further, a communication service with a high degree of safety can beprovided since the communication device allows only authenticatedterminals x to have access to the HA.

Also, if the communication device mutually connected to both zone A andzone B contains a MAP function for HMIPv6, then the communication devicecan use the HMIPv6 control signal as a trigger to initiate accessauthorization processing for zone A.

Further, if the HA1 contains a system for communicating with CA3 and asystem for holding MN4 public key certification, then prefix informationcan be reported to the MN4, after the HA1 verifies the MN4 is authenticand reports this to CA3.

1. A server system for implementation within a communication system thatincludes a terminal control device, the server system comprising: aprocessor that issues and guarantees a public key certification for aterminal device; a memory that holds prefix allocation allow/prohibitinformation of the terminal device, the prefix allocation allow/prohibitinformation indicating whether allocation of a prefix to the terminaldevice is allowed or prohibited; and a communications interface thatreceives a public key issue certification request from said terminaldevice, rewrites said prefix allocation allow/prohibit information, andcommunicates with a terminal control device to manage the terminaldevice and to manage location information of the terminal device,wherein said processor is implemented to run a first routine in whichthe public key certification issue request is received from saidterminal device, the public key certification of said terminal device isissued, said prefix allocation allow/prohibit information is rewritten,and said public key certification is sent to said terminal device, saidprocessor is implemented to run a second routine in which an inquiry onwhether prefix allocation is allowed or prohibited is received from saidterminal control device, said prefix allocation allow/prohibitinformation is searched, and the prefix allocation allow/prohibitinformation acquired is sent to said terminal control device, and theterminal control device has a DHCP-PD function and allocates prefixinformation to the terminal device based on the prefix allocationallow/prohibit information using the DHCP-PD function.
 2. Acommunication system according to claim 1, wherein said terminal createsa home address from said prefix information and a terminal interfaceidentifier.
 3. A terminal control device comprising: a connection forcommunication with a server device that issues and guarantees a publickey certification for a terminal device and that holds prefix allocationallow/prohibit information which indicates whether allocation of aprefix for the terminal device is allowed or prohibited; a transceiverthat acquires the public key certification from said server device; anda storage that holds location information for the terminal device,wherein the terminal control device implements a routine to maintainsecurity by utilizing IPsec technology through which informationconfirming an identity of said terminal device is received from saidterminal device, the public key certification for the terminal device isacquired from said server device, information allowing prefix allocationfor said terminal device is loaded from said server device, and, if saidserver device approves allocation of the prefix to said terminal device,prefix information is allocated to said terminal device, and theterminal control device has a DHCP-PD function and allocates the prefixinformation to the terminal device based on the information allowingprefix allocation for said terminal device using the DHCP-PD function toenable the terminal device to create a home address for the terminaldevice based on the prefix information and an interface identifier for acommunication interface with the server device.
 4. A terminal controldevice according to claim 3, further comprising: an informationprocessing device having a prefix allocation function, whereininformation confirming the identity of said terminal is received fromsaid terminal device, an inquiry for prefix information is made to saidinformation processor device, and a reply to the inquiry that indicatesthat said prefix was allocated is made from said information processordevice, then a reply to the information confirming said identity of theterminal is sent to said terminal device from the transceiver.
 5. Aterminal control device according to claim 3, wherein a locationregistration request or a binding update request is received from saidterminal device, and security information of said terminal device isloaded, and if said request matches said security information, thenlocation registration or binding update of said terminal device isperformed in the terminal control device.
 6. A terminal authenticationmethod for a communication system containing an information processordevice with a prefix allocation function, a server device that containsa processor and a memory and that guarantees and issues a public keycertification for a terminal device, a visited network to which theterminal device is implemented to connect, a home network which isassociated with the terminal device and which is mutually connected withsaid visited network, and a terminal control device connected to saidhome network via said visited network, the terminal authenticationmethod comprising: said server device issuing a public key certificationto said terminal device and rewriting prefix allocation information forsaid terminal device; said information processor device receiving aprefix allocation request from said terminal device, making an inquiryfor prefix allocation allow/prohibit information indicating whetherallocation of a prefix is allowed or prohibited to said server device,and notifies said terminal control device upon allocation of the prefixbeing approved; said terminal control device receiving informationconfirming the identity of the terminal device from said terminaldevice, allocating the prefix information to the terminal device basedon the information allowing prefix allocation for said terminal deviceusing a DHCP-PD function, and sending the prefix information allocatedto said terminal device to said information processor device; saidinformation processor device establishes a security association betweenthe terminal device to which said prefix information is issued and saidterminal control device; and the terminal device creating a home addressfrom the prefix information and an interface identifier for acommunication interface with the server device.
 7. A terminalauthentication method according to claim 6, wherein a communicationdevice mutually connected to the home network and the visited networksends a prefix allocation request to said information processor device.8. A terminal authentication method according to claim 7, wherein saidterminal control device receives a location registration request fromsaid terminal device, loads said security association, and approveslocation registration of said terminal device when said locationregistration request fulfills said security association.
 9. A terminalauthentication method according to claim 6, wherein said terminalcontrol device comprises a communication interface for communicatingwith said server device, and a storage device for storing public keycertification information for a terminal device; and said informationprocessor device sends prefix information to a terminal device approvedby said server device.
 10. A combination method for authentication andlocation registration of a terminal located in a visited network, themethod comprising: powering on a terminal device; sending a routeradvertisement to the terminal device from a visited network router;creating a care of address (CoA) in the terminal device; sending adevice authentication request to the visited network router; sending apublic key certification issue request with a public key and a terminalID to a calling authority server (CA) over an IP protocol network;issuing a public key certification issue response from the callingauthority server compatible with IPv6 protocol; establishing an IPsecsecurity association (SA), digital signature via IKE (internet keyexchange), and a secure communication channel using phase I and II IPsecISAKMP protocols between the terminal in the visited network and a homeagent server which is linked to the calling authority server (CA) andwhich located in a home area; making a location binding update in theterminal device using the IPsec security association (SA); sending arequest to check the public key certification to the calling authorityserver (CA) from the home agent server; holding prefix allocationallow/prohibit information of the terminal device that indicates whetherallocation of a prefix is allowed or prohibited; receiving a responsefrom the calling authority server that indicates whether prefixallocation is allowed with a prefix and creating a home address for theterminal device; discovering and obtaining a home address of the homeagent server by the terminal device; making a location binding update bythe terminal device using a binding cache from the home agent server;and thereby providing an authentication method for verifying a terminalauthenticity by linking a digital signature method with a locationbinding update method, wherein the terminal control device has a DHCP-PDfunction and allocates prefix information to the terminal device basedon the prefix allocation allow/prohibit information using the DHCP-PDfunction, and the terminal creates the home address from the prefixinformation and an interface identifier for a communication interfacewith the calling authority server.